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Abstract 

Knowledge-based program are programs with explicit tests for knowl- 
edge. They have been used successfully in a number of applications. 
Sanders has pointed out what seem to be a counterintuitive property 
of knowledge-based programs. Roughly speaking, they do not sat- 
isfy a certain monotonicity property, while standard programs (ones 
without tests for knowledge) do. It is shown that there are two ways 
of defining the monotonicity property, which agree for standard pro- 
grams. Knowledge-based programs satisfy the first, but do not satisfy 
the second. It is further argued by example that the fact that they do 
not satisfy the second is actually a feature, not a problem. Moreover, 
once we allow the more general class of knowledge-based specifications, 
standard programs do not satisfy the monotonicity property either. 
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1 Introduction 



Consider a simple program such as This program, denoted Pg 1 for future 

do forever 

if x = then y := y + 1 end 
end. 

Figure 1: The program Pg 1 

reference, describes an action that a process (or agent — I use the two words 
interchangeably here) should take, namely, setting y to y + 1, under certain 
conditions, namely, if x = 0. One way to way to provide formal semantics 
for such a program is to assume that each agent is in some local state, which, 
among other things, describes the value of the variables of interest. For this 
simple program, we need to assume that the local state contains enough 
information to determine the truth of the test x = 0. We can then associate 
with the program a protocol, that is, a function describing what action the 
agent should in each local state. Note that a program is a syntactic object, 
given by some program text, while a protocol is a function, a semantic 
object. 

Knowledge-based programs, introduced in || ^] (based on the knowledge- 
based protocols of U) are intended to provide a high-level framework for the 
design and specification of protocols. The idea is that, in knowledge-based 
programs, there are explicit tests for knowledge. Thus, a knowledge-based 
program might have the form where K{x = 0) should be read as "you know 
x = 0". We can informally view this knowledge-based program, denoted 
Pg 2 , as saying "if you know that x = 0, then set y to y + 1". Roughly 
speaking, an agent knows 92 if, in all situations consistent with the agent's 
information, <p is true. 

Knowledge-based programs are an attempt to capture the intuition that 
what an agent does depends on what it knows. They have already met with 

do forever 

if K{x = 0) then y := y + 1 end 
end, 

Figure 2: The program Pg 2 
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some degree of success, having been used in papers such as [||, ^, [TT], [L2|, [HI, 
17, 21, 22 1 both to help in the design of new protocols and to clarify the 
understanding of existing protocols. However, Sanders |25j has pointed out 
what seems to be a counterintuitive property of knowledge-based programs. 
Roughly speaking, she claims that knowledge-based programs do not satisfy 
a certain monotonicity property: a knowledge-based program can satisfy 
a specification under a given initial condition, but fail to satisfy it if we 
strengthen the initial condition. On the other hand, standard programs 
(ones without tests for knowledge) do satisfy the monotonicity property. 

In this paper, I consider Sanders' claim more carefully. I show that it 
depends critically on what it means for a program to satisfy a specification. 
There are two possible definitions, which agree for standard programs. If 
we use the one closest in spirit to the ideas presented in |J, the claim is 
false, although it is true for the definition used by Sanders. But, even in 
the case of Sanders' definition, rather than being a defect of knowledge-base 
programs, this lack of monotonicity is actually a feature. In general, we do 
not want monotonicity. Moreover, once we allow a more general class of 
knowledge-based specifications, then standard programs do not satisfy the 
monotonicity property either. 

The rest of this paper is organized as follows: In the next section, there 
is an informal review of the semantics of standard and knowledge-based pro- 
grams. In Section ||, I discuss standard and knowledge-based specifications. 
In Section ||, I consider the monotonicity property described by Sanders, and 
show in what sense it is and is not satisfied by knowledge-based programs. 
I give some examples in Section J)] showing why monotonicity is not always 
desirable. I conclude in Section g with some discussion of knowledge-based 
programs and specifications. 



2 Standard and knowledge-based programs: an 
informal review 

Formal semantics for standard and knowledge-based programs are provided 
in H M. To keep the discussion in this paper at an informal level, I simplify 
things somewhat here, and review what I hope will be just enough of the 
details so that, together with the examples given here, the reader will be 
able to follow the main points; the interested reader should refer to |], |?]] 
for further discussion and all the formal details. 

Informally, we view a distributed system as consisting of a number of 
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interacting agents. We assume that, at any given point in time, each agent 
in the system is in some local state. A global state is just a tuple consisting 
of each agent's local state, together with the state of the environment, where 
the environment consists of everything that is relevant to the system that is 
not contained in the state of the processes. The agents' local states typically 
change over time, as a result of actions that they perform. A run is a function 
from time to global states. Intuitively, a run is a complete description of 
what happens over time in one possible execution of the system. A point is a 
pair (r, m) consisting of a run r and a time m. At a point (r, m), the system 
is in some global state r(m). For simplicity, time here is taken to range 
over the natural numbers (so that time is viewed as discrete, rather than 
continuous). A system 1Z is a set of runs; intuitively, these runs describe all 
the possible executions of the system. For example, in a poker game, the 
runs could describe all the possible deals and bidding sequences. 

Of major interest in this paper are the systems that we can associate 
with a program. To do this, we must first associate a system with a joint 
protocol. As was said in the introduction, a protocol is a function from local 
states to actions. (This function may be nondeterministic, so that in a given 
local state, there is a set of actions that may be performed.) A joint protocol 
is just a set of protocols, one for each process. 

While the joint protocol describes what each process does, it does not 
give us enough information to generate a system. It does not tell us what the 
legal behaviors of the environment are, the effects of the actions, or the initial 
conditions. We specify these in the context. Formally, a context 7 is a tuple 
(P e , Go, r, \E'), where P e is a protocol for the environment, Qq is a set of initial 
global states, r is a transition function, and ^ is a set of admissible runs. The 
environment is viewed as running a protocol just like the agents; its protocol 
is used to capture features of the setting like "all messages are delivered 
within 5 rounds" or "messages may be lost". Given a joint protocol P = 
(Pi, . . . ,P n ) for the agents, an environment protocol P e , and a global state 
(s e , s±, . . . , s n ), there is a set of possible joint actions (a e , ai, . . . , a n ) that can 
be performed in this global state according to the protocols of the agents and 
the environment. (It is a set since the protocols may be nondeterministic.) 
The transition function r describes how these joint actions change the global 
state by associating with each joint action a global state transformer, that 
is, a mapping from global states to global states. The set of admissible 
runs is used to characterize notions like fairness. For the simple programs 
considered in this paper, the transition function will be almost immediate 
from the description of the global states and \I> will typically consist of all 
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runs (so that it effectively plays no interesting role). What will change as 
we vary the context is the set of possible initial global states. 

A run r is consistent with joint protocol P in context 7 if (1) r(0), the 
initial global state of r, is one of the initial global states in Qq, (2) for all m, 
the transition from global state r(m) to r(m + 1) is the result of applying r 
to a joint action that can be performed by (P e , P) in the global state r(m), 
and (3) r £ $. A system 7Z represents a joint protocol P in context 7 if it 
consists of all runs consistent with P in 7. 

Assuming that each test in a standard program run by process i can be 
evaluated in each local state, we can derive a protocol from the program in 
an obvious way: to find out what process i does in a local state £, we evaluate 
the tests in Pg in I and perform the appropriate action.^] A run is consistent 
with Pg in context 7 if it is consistent with the protocol derived from Pg. 
Similarly A system represents Pg in context 7 if it represents the protocol 
derived from Pg. We use R(Pg, 7) to denote the system representing Pg in 
context 7. 

Example 2.1: Consider the simple standard program Pg l in Figure [l] and 
suppose there is only one agent in the system. Further suppose the agent's 
local state is a pair of natural numbers (a,b), where a is the current value 
of variable x and b is the current value of y. The protocol derived from Pg l 
increments the value of b by 1 precisely if a = 0. In this simple case, we can 
ignore the environment state, and just identify the global state of the system 
with the agent's local state. Suppose we consider the context 7 where the 
initial states consist of all possible local states of the form (a, 0) for a > 
and the transition function is such that the action y := y + 1 transforms (a, b) 
to (a, b + 1). We ignore the environment protocol (or, equivalently, assume 
that P e performs the action no-op at each step) and assume ^/ consist of all 
runs. A run r is then consistent with Pg x in context 7 if either (1) r(0) is of 
the form (0, b) and r(m) is of the form (0, b + m) for all m > 1, or (2) r(m) 
is of the form (a, b) for all m and a > 0. That is, either the x component is 
originally 0, in which case the y component is continually increased by 1, or 
else nothing happens. I 

Now we turn to knowledge-based programs. Here the situation is some- 
what more complicated. In a given context, a process can determine the 

1 Strictly speaking, to evaluate the tests, we need an interpretation that assigns truth 
values to formulas in each global state. For the programs considered here, the appro- 
priate interpretation will be immediate from the description of the system, so I ignore 
interpretations here for ease of exposition. 
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truth of a test such as a x = 0" by simply looking at its local state. However, 
in a knowledge-based program, there are tests for knowledge. According to 
the definition of knowledge in systems, an agent i knows a fact ip at a given 
point (r, m) in system 1Z if (p is true at all points in 1Z in which i has the 
same local state as it does at (r, m). Thus, i knows (p at the point (r, to) 
if ip holds at all points consistent with i's information at (r, to). The truth 
of a test for knowledge cannot in general be determined simply by looking 
at the local state in isolation. We need to look at the whole system. As a 
consequence, given a run, we cannot in general determine if it is consistent 
with a knowledge-based program in a given context. This is because we 
cannot tell how the tests for knowledge turn out without being given the 
other possible runs of the system; what a process knows at one point will 
depend in general on what other points are possible. This stands in sharp 
contrast to the situation for standard programs. 

This means it no longer makes sense to talk about a run being consistent 
with a knowledge-based program in a given context. However, notice that, 
given a system 7Z, we can derive a protocol from a knowledge-based program 
Pg^ for process i by using 1Z to evaluate the knowledge tests in Pg^ . That 
is, a test such as K<p holds in a local state I if cp holds at all points in 
1Z where process i has local state I. In general, different protocols can be 
derived from a given knowledge-based program, depending on what system 
we use to evaluate the tests. Let Pg^| denote the protocol derived from Pg fc6 
given system 7Z. 

We say that a system 1Z represents a knowledge-based program Pg^ in 
context 7 if 1Z represents the protocol Pgjyj. That is, 1Z represents Pg fcfe 
if 1Z = R(Pg||,7). Thus, a system represents Pg fc6 if it satisfies a certain 
fixed-point equation. 

This definition is somewhat subtle, and determining the system rep- 
resenting a given knowledge-based program may be nontrivial. Indeed, 
as shown in |], Rj], in general, there may be no systems representing a 
knowledge-based program Pg^ in a given context, only one, or more than 
one, since the fixed-point equation may have no solutions, one solution, or 
many solutions. Moreover, computing the solutions may be a difficult task, 
even if we have only finitely many possible global states. There are condi- 
tions sufficient to guarantee that there is exactly one system representing 
Pg fcfe , and these conditions are satisfied by many knowledge-based programs 
of interest, and, in particular, by the programs discussed in this paper. If 
Pg fcfc has a unique system representing it in context 7, then we again denote 
this system R(Pg fcfe ,7). 
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Example 2.2: The knowledge-based program Pg 2 in Figure ^, with the 
test K(x = 0), is particularly simple to analyze. If we consider the context 



7 discussed in Example 2.1, then whether or not x = holds is determined 
by the process' local state. Thus, in context 7, x = holds iff K(x = 0) 
holds, and the knowledge-based program reduces to the standard program. 

On the other hand, consider the context 7' where the agent's local state 
just consists just of the value of y, while the value of x is part of the en- 
vironment state. Again, we can identify the global state with a pair (a, b), 
where a is the current value of x and b is the current value of y, but now 
a represents the environment's state, while b represents the agent's state. 
We can again assume the environment performs the no-op action at each 



step, consists of all runs, the transition function is as in Example 2.1, 
and the initial states are all possible global states of the form (a, 0). In this 
context, there is a also unique system representing Pg 2 : The agent never 
knows whether x = 0, so there is a unique run corresponding to each initial 
state (a, 0), in which the global state is (a,0) throughout the run. 

Finally, let 7" be identical to 7' except that the only initial state is (0, 0). 
Again, there will be a unique system representing Pg 2 in 7", but it is quite 
different from R(Pg 2 ,7'). In R(Pg 2 ,7"), the agent knows that x = at all 
times. There is only one run, where the value of y is augmented at every 
step. I 

This discussion suggests that a knowledge-based program can be viewed 
as specifying a set of systems, the ones that satisfy a certain fixed-point 
property, while a standard program can be viewed as specifying a set of 
runs, the ones consistent with the program. 



3 Standard and knowledge-based specifications 

Typically, we think of a protocol being designed to satisfy a specification, 
or set of properties. Although a specification is often written in some speci- 
fication language (such as temporal logic), many specifications can usefully 
be viewed as predicates on runs. This means that we can associate a set 
of runs with a specification; namely, all the runs that satisfy the required 
properties. Thus, a specification such as "all processes eventually decide 
on the same value" would be associated with the set of runs in which the 
processes do all decide the same value.0 

2 Of course, there are useful specifications that cannot be viewed as predicates on runs. 
While linear time temporal logic assertions are predicates on runs, branching time tempo- 



6 



Researchers have often focused attention on two types of specifications: 
safety properties — these are invariant properties that have the form "a par- 
ticular bad thing never happens" — and liveness properties — these are prop- 
erties that essentially say "a particular good thing eventually does happen" 
p4| . Thus, a run r has a safety property p if p holds at all points (r, to), 
while r has the liveness property q if q holds at some point (r, m). Sup- 
pose we are interested in a program that guarantees that all the processes 
eventually decide on the same value. We model this by assuming that each 
process i has a decision variable Xi, initially undefined, in its local state (we 
can assume a special "undefined" value in the domain), which is set once 
in the course of a run, when the decision is made. Given the way we have 
chosen to model this problem, we would expect this program to satisfy two 
safety properties: (1) each process' decision variable is changed at most once 
(so that it is never the case that it is set more than once); and (2) if neither 
Xi nor Xj has value "undefined", then they are equal. We also expect it to 
satisfy one liveness property: each decision variable is eventually set. 

We say that a standard program Pg satisfies a specification a in a context 
7 if every run consistent with Pg in 7 (that is, every run in the system 
representing Pg in 7) satisfies a. Similarly, we can say that a knowledge- 
based program Pg^j satisfies specification a in context 7 if every run in every 
system representing Pg fc6 satisfies o. 

The notion of specification we have considered so far can be thought of 
as being run based. A specification a is a predicate on (i.e., set of) runs 
and a program satisfies a if each run consistent with the program is in a. 
Although run-based specifications arise often in practice, there are reason- 
able specifications that are not run based. There are times that it is best to 
think of a specification as being, not a predicate on runs, but a predicate on 
entire systems. For example, consider a knowledge base (KB) that responds 
to queries by users. We can imagine a specification that says "To a query 

ral logic assertions are best viewed as predicates on trees. (See ^, [L6| for a discussion of 
the differences between linear time and branching time.) For example, Koo and Toueg's 
notion of weak termination [Q requires that at every point there is a possible future 
where everyone terminates. In the notation used in this paper, this would mean that for 
every point (r, m), there must be another point (r',m) such that r and r' are identical 
up to time m, and at some point (r',m') with m' > m, every process terminates. This 
assertion is easily expressed in branching time logic. Probabilistic assertions such as "all 
processes terminate with probability .99" also cannot be viewed as predicates on individ- 
ual runs. Other examples of specifications that cannot be viewed as a predicate on runs 
are discussed later in this section. Nevertheless, specifications that are predicates on runs 
are sufficiently prevalent that it seems reasonable to give them special attention. 
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of <p, answer 'Yes' if you know <p, answer 'No' if you know —up, otherwise 
answer 'I don't know'." This specification is given in terms of the KB's 
knowledge, which depends on the whole system and cannot be determined 
by considering individual runs in isolation. We call such a specification 
a knowledge-based specification. Typically, we think of a knowledge-based 
specification being given as a formula involving operators for knowledge and 
time. Formally, it is simply a predicate on (set of) systems. (Intuitively, 
it consists of all the systems where the formula is valid — i.e., true at every 
point in the system. |] 

We can think of a run-based specification a as a special case of a knowledge- 
based specification. It consists of all those systems all of whose runs satisfy 
a. A (standard or knowledge-based) program Pg satisfies a knowledge-based 
specification a in context 7 if every system representing Pg in 7 satisfies the 
specification. 

Notice that knowledge-based specifications bear the same relationship 
to (standard) specifications as knowledge-based programs bear to standard 
programs. A knowledge-based specification/program in general defines a 
set of systems; a standard specification/program defines a set of runs (i.e., 
a single system). 



4 Monotonicity 



Sanders p5fl focuses on a particular monotonicity property of specifications. 
To understand this property, and Sanders' concerns, we first need some 
definitions. Given contexts 7 = (P e , Qo, r, \E') and 7' = {P' e , Q' Q , t' , \E ,/ ), we 
write i C 7 if P e = P' e , % C Q , r = r', and *' C That is, in 7' 
there may be fewer initial states and fewer admissible runs, but otherwise 
7 and 7' are the same. The following lemma is almost immediate from the 
definitions. 

Lemma 4.1: If j' C 7, then for all protocols P, every run consistent with 
P in 7' is also consistent with P in 7, so R(P, 7') C R(P, 7). Similarly, for 
every standard program Pg, we have R(Pg,7') C R(Pg, 7). 



The restriction in Lemma 4.1 to standard programs is necessary. It is 



not true for knowledge-based programs. The set of systems consistent with 

3 As the examples discussed in Footnote 2 show, not all predicates on systems can 
be expressed in terms of formulas involving knowledge and time. I will not attempt to 
characterize here the ones that can be so expressed. It is not even clear that such a 
characterization is either feasible or useful. 
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a knowledge-based program can be rather arbitrary, as Example 2.2 shows. 
This example also shows that safety and liveness properties need not be 
preserved when we restrict the context. The safety property "y is never 
equal to 1" is satisfied by Pg 2 in context 7' but not in context 7". On the 
other hand, the liveness property "y is eventually equal to 1" is satisfied by 
Pg 2 in context 7" but not 7'. 

Sanders suggests that this behavior is somewhat counterintuitive. To 
quote p5[: 



[A] knowledge-based protocol need not be monotonic with respect 
to the initial conditions ... [In particular,] safety and liveness 
properties of knowledge-based protocols need not be preserved by 
strengthening the initial conditions, thus violating one of the 
most intuitive and fundamental properties of standard programs 
[italics Sanders'] .0 

It is certainly true that the system representing a knowledge-based pro- 
gram in a restricted context is not necessarily a subset of the system repre- 
senting it in the original context. However, under what is arguably the most 
natural interpretation of what it means for a program to satisfy a specifi- 
cation with respect to an initial condition, a knowledge-based program is 
monotonic with respect to initial conditions. 

To understand why this should be so, we need to make precise what 
it means for a (knowledge-based) program to satisfy a specification with 
respect to an initial condition. Formally, we can take an initial condition to 
be a predicate on global states (so that an initial condition corresponds to a 
set of global states). An initial condition INIT' is a strengthening of INIT 
if INIT' is a subset of INIT. (In logical terms, this means that INIT' can 
be thought of as implying INIT.) A set G of global states satisfies an initial 
condition INIT if G C INIT. 

Suppose that we fix P e , r, and ^f, that is, all the components of a 
context except the set of initial global states, and consider the family T = 
r(P e , r, ^S>) of contexts of the form [P e , Go, r, *), where the set Go varies over 
all subsets of global states. Now it seems reasonable to say that program 
Pg satisfies specification a (with respect toT) given initial condition INIT if 
Pg satisfies a in every context in T whose initial global states satisfy INIT. 



4 In |{|, a notion of knowledge-based protocol was introduced, and Sanders is referring 
to that notion, rather than the notion of knowledge-based program that I am using here. 
See j?J for a discussion of the difference between the two notions. Sanders' comments 
apply without change to knowledge-based programs as defined here. 
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With this definition, it is clear that if Pg satisfies a given INIT, and INIT' 
is a strengthening of INIT, then Pg must also satisfy a with respect to 
INIT', since every context whose initial global states are in INIT' also has 
its initial global states in INIT. 

Thus, under this definition of what it means for a program to satisfy 
a specification, Sanders' observation is incorrect. However, Sanders used a 
somewhat different definition. Suppose that rather than considering all con- 
texts in r whose initial global states satisfy INIT, we consider the maximal 
one, that is, the one whose set of initial global states consists of all global 
states in £ that satisfy INIT. We say that Pg maximally satisfies specifica- 
tion <7 (with respect to T) given INIT if Pg satisfies a in the context in T 
whose set of initial global states consists of all global states satisfying INIT. 

It is almost immediate from Lemma iA and the definitions that for 
standard programs and standard specifications, "satisfaction with respect 
to T" coincides with "maximal satisfaction with respect to T". On the 
other hand, they can be quite different for knowledge-based programs and 
knowledge-based specifications, as the following examples show. 



Example 4.2: For the knowledge-based program Pg 2 , if we take T to con- 
sist of all contexts (P e , Go, r, where P e , t, and are as discussed in 
Example [T^ and Qq is some subset of the global states, then, as we observed 
above, Pg 2 satisfies the specification "y is never equal to 1" for the initial 
condition INIT\ which can be characterized by the formula y = but not 
for the initial condition INIT2 characterized by x = A y = 0. Similarly, if 
Pg 3 is the result of replacing the test K(x = 0) in Pg 2 by ^K(x = 0), then 
Pg 3 satisfies the liveness condition "y is eventually equal to 1" for INIT\ but 
not for INIT 2- This shows that a standard specification (in particular, one 
involving safety or liveness) may not be monotonic with respect to maximal 
specification for a knowledge-based program. | 



Example 4.3: Consider the standard program Pg x again, but now consider 
a context where there are two agents. Intuitively, the second agent never 
learns anything and plays no role. Formally, this is captured by taking the 
second agent's local state to always be A. Thus, a global state now has the 
form ({a, b),\). We can again identify the global state with the local state of 
the first agent (the one performing all the actions). Thus, abusing notation 
somewhat, we can consider the same set of contexts as in Example L2. Now 
consider the knowledge-based specification Kii^) = 0). This is true with 
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respect to T for the initial condition INIT\ but not for INIT2- This shows 
that even for a standard program, a knowledge-based specification may not 
be monotonic with respect to maximal satisfaction. | 



Example 4.4: In the muddy children problem discussed in [10], the father 
of the children says "Some [i.e., one or more] of you have mud on your fore- 
head." The father then repeatedly asks the children "Do you know that 
you have mud on your own forehead?" Thus, the children can be viewed 
as running a knowledge-based program according to which a child answers 
"Yes" iff she knows that she has mud on her forehead. The father's initial 
statement is taken to restrict the possible initial global states to those where 
one or more children have mud on their foreheads. It is well known that, 
under this initial condition, the knowledge-based program satisfies the live- 
ness property "all the children with mud on their foreheads eventually know 
it" . On the other hand, if the father instead gives the children more initial 
information, by saying "Child 1 has mud on his forehead" (thus restricting 
the set of initial global states to those where child 1 has mud on his fore- 
head), none of the children that have mud on their forehead besides child 
1 will be able to figure out that they have mud on their forehead. Roughly 
speaking, this is because the information available to the children from child 
l's "No" answer in the original version of the story is no longer available 
once the father gives the extra information. (See |], Example 7.25].) This 
problem is not an artifact of using knowledge-based programs or specifica- 
tions. Rather, it is really the case in the original puzzle that if the father 
had said "Child 1 has mud on his forehead" rather than "Some of you have 
mud on your foreheads", the children with mud on their foreheads would 
never be able to figure out that they had mud on their foreheads. Sometimes 
extra knowledge can be harmful!^ I 

As should be clear from the preceding discussion, there are two notions of 
monotonicity, which happen to coincide (and hold) for standard programs 
and specifications, but differ if we consider knowledge-based programs or 
knowledge-based specifications. For knowledge-based programs and speci- 
fications, the first notion of monotonicity holds, while the second (mono- 
tonicity with respect to maximal satisfaction) does not. Monotonicity is 

Another example of the phenomenon that extra knowledge can be harmful can be 
found in poj. This is also a well-known phenomenon in the economics/game theory 
literature pal. 
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certainly a desirable property — for a monotonic specification and program, 
once we prove that the specification holds for the program for a given initial 
condition, then we can immediately conclude that it holds for all stronger 
specifications. Without monotonicity, one may have to reprove the prop- 
erty for all stronger initial conditions. Maximal satisfaction also certainly 
seems like a reasonable generalization from the standard case. Thus, we 
should consider to what extent it is a problem that we lose monotonicity 
for maximal satisfaction when we consider knowledge-based programs and 
specifications. 

Of course, whether something is problematic is, in great measure, in the 
eye of the beholder. Nevertheless, I would claim that, in the case of maximal 
satisfaction, the only properties that are lost when the initial condition is 
strengthened are either unimportant properties, or properties that, roughly 
speaking, ought to be lost. More precisely, they are properties that happen 
to be true of a particular context, but are not intrinsic properties of the pro- 
gram. The examples and the technical discussion below should help to make 
the point clearer. Thus, this lack of monotonicity should not be viewed as a 
defect of knowledge-based programs and specifications. Rather, it correctly 
captures the subtleties of knowledge acquisition in certain circumstances. 



5 Some examples 

Consider again the program Pg 2 . It can be viewed as saying "perform a 
sequence of actions (continually increasing y) if you know that x = 0" . In 
the system R(Pg 2 ,7'), the initial condition guarantees that the agent does 
not know the value of x, and thus nothing is done. The strengthening of 
the initial condition tox = 0Ay = described by 7" guarantees that the 
agent does know that x = 0, and thus actions are performed. In this case, 
we surely do not want a safety condition like "y is never equal to 1", which 
holds if the sequence of actions is not performed, to be preserved when we 
strengthen the initial condition in this way. Similarly, for the program Pg 3 



defined in Example ^2, where the action is performed if the agent does 
not know that x = 0, we would not expect a liveness property like "y is 
eventually equal to 1" to be preserved. 

Clearly, there are times when we would like a safety or a liveness prop- 
erty to be preserved when we strengthen initial conditions. But these safety 
or liveness properties are typically ones that we want to hold of all systems 
consistent with the knowledge-based program, not just the ones represent- 
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ing the program in certain maximal contexts. The tests in a well-designed 
knowledge-based program are often there precisely to ensure that desired 
safety properties do hold in all systems consistent with the program. For 
example, there may be a test for knowledge to ensure that an action is per- 
formed only if it is known to be safe (i.e., it does not violate the safety 
property). It is often possible to prove that such safety properties hold in 
all systems consistent with the knowledge-based program; thus, the issue of 
needing to reprove the property if we strengthen the initial conditions does 
not arise. (See || pp. 259-270] for further discussion of this issue.) 

In the case of liveness properties, we often want to ensure that a given 
action is eventually performed. It is typically the case that an action in 
a knowledge-based program is performed when a given fact is known to be 
true. Thus, the problem reduces to ensuring that the knowledge is eventually 
obtained. As a consequence, the knowledge-based approach often makes it 
clearer what is required for the liveness property to hold. One example of 
how safety properties can be ensured by appropriate tests for knowledge and 
how liveness properties reduce to showing that a certain piece of knowledge 
is eventually obtained is given by the knowledge-based programs of [O]. I 
illustrate these points here using a simpler example. 

Suppose we have a network of n processes, connected via a communi- 
cation network. The network is connected, but not necessarily completely 
connected. For simplicity, assume each communication link is bidirectional. 
We assume that all messages arrive within one time unit. Each process 
knows which processes it is connected to; formally, this means that the local 
state of each process includes a mapping associating each outgoing link with 
the identity of the neighbor at the other end. We also assume that each 
process records in its local state the messages it has sent and received. We 
want a program for process 1 to broadcast a binary value to all the pro- 
cesses in the network. Formally, we assume that each process i has a local 
variable, say Xi, which is intended to store the value. The specification that 
the program must satisfy consists of three properties. For every run, and 
for all i = 1, . . . , n, we require the following: 

1. Xi changes value at most once, 

2. x\ never changes value, and 

3. eventually the value of Xi is equal to that of x\. 

Note that the first two properties are safety properties, and the last is a 
liveness property. 
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A simple standard program that satisfies this specification is for process 
1 to send v, the value of x\, to all its neighbors; then the first time process 
i (i 7^ 1) gets the value v, it sets X{ to v and sends v to all its neighbors 
except the one from which it received the message. Process i does nothing 
if it later gets the value v again. This program is easily seen to satisfy the 
specification in the context implicitly described above. We remark that, in 
principle, we could modify the first property to allow x\ to change value 
a number of times before finally "stabilizing" on a final value. However, 
allowing this would only complicate the description of the property, since 
we would have to modify the third property to guarantee that the value of 
Xi after stabilizing is equal to that of x\. We return to this point below. 

The behavior of each process can easily be captured in terms of knowl- 
edge: When a process knows the value of x\, it sends the value to all its 
neighbors except those that it knows already know the value of x\. Let 
Ki{x\) be an abbreviation for "process i knows the value of x\" . (Thus, 
Ki{x\) is an abbreviation for Ki(x\ = 0) V Ki(x\ = 1).) Similarly, let 
KiKj(xi) be an abbreviation for "process i knows that process j knows the 
value of xi" Then we have the joint knowledge-based program DIFFUSE = 
(DIFFUSEi, . . . , DIFFUSE n ), where DIFFUSE;, the program followed by pro- 
cess i, is 

do forever 

if Ki{ Xl ) 
then 

Xi . — X\ , 

for each neighbor j of i 
do 

if -^KiKj(xi) then send the value of x\ to j end 
end 
end 
end. 

By considering this knowledge-based program, we abstract away from the 
details of how i gains knowledge of the value of x\. If i = 1, then presumably 
the value was known all along; otherwise it was perhaps acquired through 
the receipt of a message. Similarly, the fact that i sends the value of X\ to 
a neighbor j only if i doesn't know that j knows the value of x\ handles 
two of the details of the standard program: (1) it guarantees that i does 
not send the value of X\ to j if i received the value of X\ from j, and (2) it 
guarantees that i does not send the value of x\ to its neighbors more than 
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once.0 Finally, observe that DIFFUSE is correct even if messages can be 
lost, as long as the system satisfies an appropriate fairness assumption (if a 
message is sent infinitely often, it will eventually be delivered).]] In this case 
process i would keep sending the value of x\ to j until i knows (perhaps by 
receiving an acknowledgment from j) that j knows the value of x\. The fact 
that DIFFUSE is correct "even if messages can be lost" or "no matter what 
the network topology" means that the program meets its specification in a 
number of different contexts. 

This knowledge-based program has another advantage: it suggests ways 
to design more efficient standard programs. For example, process i does 
not have to send the value of x\ to all its neighbors (except the one from 
which it received the value of x\) if it has some other way of knowing that 
a neighbor already knows the value of x\. This may happen if the value 
of x\ has a header describing to which processes it has already been sent. 
It might also happen if the receiving process has some knowledge of the 
network topology (for example, there is no need to rebroadcast the value of 
x\ if communication is reliable and all processes are neighbors of process 1). 

Returning to our main theme, notice that in every context 7 consistent 
with our assumptions, in the system(s) representing DIFFUSE in 7, the three 
properties described above are satisfied: X{ changes value at most once in 
any run, x\ never changes value, and eventually the value of x% is equal to 
that of x\. Notice also the role of the test Ki(x\) in ensuring that the safety 
properties hold. As a result of the test, we know that Xi is not updated 
until the value of x\ is known; when it is updated, it is set to x\. This 
guarantees that x\ never changes value, and that x% changes value at most 
once and, when it does, it is set to X\. All that remains is to guarantee that 
Xi is eventually set to x\. What the knowledge-based program makes clear 
is that this amounts to ensuring that all processes eventually know the value 
of x\. It is easy to prove that this is indeed the case. 

It is also easy to see that there are other properties that do not hold 
in all contexts. For a simple example, suppose that n = 3, so there are 

6 This argument depends in part on our assumption that process i is keeping track of 
the messages it sends and receives. If i forgets the fact that it received the value of x\ 
from j then (if i follows DIFFUSE^), it would send the value of Xi back to j. Similarly, 
if i receives the value of xi a second time and forgets that it has already sent it once 
to its neighbors, then according to DIFFUSE^, it would send it again. In addition, the 
assumption that there are no process failures is crucial. 

7 Note that this fairness assumption can be captured by using an appropriate set ^ 
(consisting only of runs where the fairness condition is satisfied) in the context. 
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three processes in the network. Suppose that there is a link from process 

1 to process 2, and a link from process 2 to process 3, and that these are 
the only links in the network. Moreover, suppose that the network topology- 
is common knowledge. Given these simplifying assumptions, a process i's 
initial state consists of an encoding of the network topology, its name, and 
the value of x«. Now consider two contexts: in context 71, there are 8 initial 
global states, in which (x±, X2, X3) take on all values in {0, l} 3 ; in 72, there 
are 4 initial global states, in which (xi, X2, £3) take on all values in {0, l} 3 
such that x\ = X3. Intuitively, in context 72, process 3 knows the value 
of x\ (since it is the same as the value of X3, which is part of process 3's 
initial state), while in 7 1; neither process 2 nor process 3 know the value 
of x x . Let Tlx = R(DIFFUSE,7i) and let TZ 2 = R(DIFFUSE, 72). It is not 
hard to see that 1Z\ has eight runs, one corresponding to each initial global 
state. In each of these runs, process 1 sends the value of x\ to process 2 in 
round 1; process 2 sets X2 to this value in round 2 and forwards the value to 
process 3; in round 3, process 3 sets X3 to i (and sends no messages). (Note 
that, formally, round k takes place between times k — 1 and k.) Similarly, 
72-2) has four runs, one corresponding to each initial global state. In these 
runs, process 3 initially knows the value of x\, although process 2 does not. 
Moreover, process 2 knows this. Thus, in the round of the runs in IZ2, both 
process 1 and process 3 send the value of x\ to process 2. But now, process 

2 does not send a message to process 3 in the second round. 

As expected, we can observe that not all liveness properties are pre- 
served as we move from 7£i to 7^2 • For example, the runs in TL\ all satisfy 
the liveness property "eventually process 2 sends a message to process 3". 
Clearly the runs in 7^2 do not satisfy this liveness property. This should 
be seen as a feature, not a bug! There is no reason to preserve the sending 
of unnecessary messages. The extra knowledge obtained when the initial 
conditions are strengthened may render sending the message unnecessary. 

6 Discussion 

When designing programs, we often start with a specification and try to find 
an (easily-implementable) standard program that satisfies it. The process 
of going from a specification to an implementation is often a difficult one. I 
would argue that quite often it is useful to express the properties we desire 
using a knowledge-based specification, proceed from there to construct a 
knowledge-based program, and then go from the knowledge-based program 
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to a standard program. While this approach may not always be helpful 
(indeed, if a badly designed knowledge-based program is used, then it may 
actually be harmful), there is some evidence showing that it can help. 

The first examples of going from knowledge-based specifications to (stan- 
dard) programs can be found in Q ||, |l5| (although the formal model used 
in [HJ is somewhat different from that described here). The approach 
described here was used in [O] to derive solutions to the sequence transmis- 
sion problem (the problem of transmitting a sequence of bits reliably over 
a possibly faulty communication channel). All the programs derived in |l^] 
are (variants of) well-known programs that solved the problem. While I 
would argue that the knowledge-based approach shows the commonality in 
the approaches used to solve the problem, and allows for easier and more 
uniform proofs of correctness, certainly this example by itself is not convinc- 
ing evidence of the power of the knowledge-based approach. 

Perhaps more convincing evidence is provided by the results of [||, [II], 



21 1, where this approach is used to derive programs that are optimal (in 
terms of number of rounds required) for Byzantine Agreement and Eventual 
Byzantine Agreement. In this case, the programs derived were new, and it 
seems that it would have been quite difficult to derive them directly from 
the original specifications. 

Knowledge-based specifications are more prevalent than it might at first 
seem. We are often interested in constructing programs that not only sat- 
isfy some safety and liveness conditions, but also use a minimal number of 
messages or rounds. As we have already observed, specifications of the form 
"do not send unnecessary messages" are not standard specifications; the 
same is true for a specification of the form "halt as soon as possible" . Such 
specifications can be viewed as knowledge-based specifications. The results 
of || [Tl], |2l]] can be viewed as showing how knowledge-based specifications 
arise in the construction of round-efficient programs. The tests for knowl- 
edge in the knowledge-based programs described in these papers explicitly 
embody the intuition that a process decides as soon as it is safe to do so. 

Similar sentiments about the importance of knowledge-based specifica- 
tions are expressed by Mazer fli~8|| (although the analogy between knowledge- 
based programs and knowledge-based specifications is not made in that pa- 
per): 

Epistemic [i.e., knowledge-based] specifications are surprisingly 
common: a problem specification that asserts that a property 
or value is private to some process is an epistemic specifica- 
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tion (e.g., "each database site knows whether it has committed 
the transaction"). We are also interested in epistemic proper- 
ties to capture assertions on the extent to which a process's lo- 
cal state accurately reflects aspects of the system state, such as 
"each database site knows whether the others have committed 
the transaction". 

For another example of the usefulness of knowledge-based specifications, 
recall our earlier discussion of the specification of the program for broadcast- 
ing a message through a network. If we replace the liveness requirements 
by the simple knowledge-based requirement "eventually process i knows the 
value of xi" , we can drop the first property (that X{ changes value at most 
once) altogether. Indeed, we do not have to mention Xi, i ^ 1, at all. 
The knowledge-based specification thus seems to capture our intuitive re- 
quirements for the program more directly and elegantly than the standard 
specification given. 

A standard specification can be viewed as a special case of a knowledge- 
based specification, one in which the set of systems satisfying it is closed 
under unions and subsets. It is because of these closure properties that we 
have the property if a standard program satisfies a standard specification 
a in a context 7, then it satisfies it in any restriction of 7. Clearly, this is 
not a property that holds of standard programs once we allow knowledge- 
based specifications. Nevertheless, as the examples above suggest, there 
is something to be gained — and little to be lost — by allowing the greater 
generality of knowledge-based specifications. In particular, although we do 
lose monotonicity, there are other ways of ensuring that safety and liveness 
properties do hold in the systems of interest. 

By forcing us to think in terms of systems, rather than of individual runs, 
both knowledge-based programs and knowledge-based specifications can be 
viewed as requiring more "global" thinking than their standard counterparts. 
The hope is that thinking at this level of abstraction makes the design and 
specification of programs easier to carry out. 

We still need more experience using this framework before we can de- 
cide whether this hope will be borne out and whether the knowledge-based 
approach as described here is really useful. Sanders has other criticisms of 
the use of knowledge-based programs that I have not addressed here. Very 
roughly, she provides pragmatic arguments that suggest that we use predi- 
cates that have some of the properties of knowledge (for example Kip =4* 92), 
but not necessarily all of them. This theme is further pursued in || . While I 
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believe that using predicates that satisfy some of the properties of knowledge 
will not prove to be as useful as sticking to the original notion of knowledge, 
we clearly need more examples to better understand the issues. 



Besides more examples, as pointed out by Sanders [25], it would also 
be useful to have techniques for reasoning about knowledge-based programs 
without having to construct the set of runs generated by the program. In 
||, a simple knowledge-based programming language is proposed. Perhaps 
standard techniques for proving program correctness can be applied to it 
(or some variant of it). A first step along these lines was taken by Sanders 
p5[ , who extended UNITY [0] in such a way as to allow the definition 
of knowledge predicates (although it appears that the resulting knowledge- 
based programs are somewhat less general than those described here), and 
then used proof techniques developed for UNITY to prove the correctness 
of another knowledge-based protocol for the sequence transmission problem. 
(We remark that techniques for reasoning about knowledge obtained in CSP 
programs, but not for knowledge-based programs, were given in Jl3|].) Once 
we have a number of examples and better techniques in hand, we shall need 
to carry out a careful evaluation of the knowledge-based approach, and a 
comparison of it and other approaches. I believe that once the evidence is in, 
it will show that there are indeed significant advantages that can be gained 
by thinking at the knowledge level. 
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